Modern digital applications heavily rely on the secure exchange of data. Digital content, including digital audio and video, for example, is often stored, and transmitted in encrypted form, for later decryption by authorized recipients. Not surprisingly, many encryption/decryption techniques are known.
For example, the High-bandwidth Digital Content Protection (HDCP) protocol is used to protect digital data video streams over a high bandwidth point-to-point link. HDCP is for example used by displays interconnected with video sources over the High Definition Multimedia Interface (HDMI) and the Digital Video Interface (DVI).
HDCP utilizes an initial authentication phase to initialize a cipher engine that is then used to create pseudo-random encryption cipher stream that is then XORed (Exclusive Or) with the data stream that is to be protected. The resulting data stream cannot be deciphered without generating a decryption cipher stream identical to the encryption cipher stream, and XORing it with the protected data stream to recover the initial data. A simple HDCP transmitter/receiver system 100 is shown in FIG. 1.
System 100 includes a transmitter 110 and a receiver 120. Transmitter 110 includes an HDCP engine 112 that produces HDCP cipher data for encrypting data from a data source 114. The cipher data is combined with the data from the data source using an XOR gate 116, thereby producing a protected data stream 140.
Receiver 120 includes an HDCP engine 124 that, like HDCP engine 112, produces HDCP cipher data for decrypting the protected data stream 140. The HDCP cipher data is combined with the protected data stream 140 using an XOR gate 126, the output which is directed to a data sink 124.
HDCP engines 112 and 122 exchange control and authentication information 130 to ensure that they are authorised to perform the encryption/decryption requested and to ensure that they are synchronized with each other.
Transmitter 110 and receiver 120 must periodically re-initialize (i.e., re-key). This is done for each line of video, and for each frame of video provided by transmitter 110. Re-keying makes sure that the transmitter 110 is in synch with receiver 120. After each line, the HDCP system performs a soft re-key that typically takes 58 cycles. After each frame, a hard re-key is performed for which 142 cycles are allocated.
Unfortunately, encryption is not possible during the re-key periods, as cipher engines 112 and 122 do not generate encryption data during these periods. As HDCP is typically used to protect rasterized video, vertical and horizontal blank intervals accommodate this periodic re-keying, allowing cipher engines 112 and 122 to generate intermittent encryption/decryption cipher streams without affecting the encryption or decryption of the data stream.
FIG. 2 shows an example of HDCP rasterized video 200. The rasterized video includes active video data 210, during which time HDCP is active. The rasterized video also includes a vertical 220 and a horizontal blank 230, corresponding to traditional vertical and horizontal blanking intervals. Ancillary data 222 may optionally be embedded in the blanking intervals. Encryption and decryption streams stop for those portions of the vertical and horizontal blanks 220 and 230 not containing ancillary data 240. Per frame re-keying 240 and per-line re-keying can take place during the vertical and/or the horizontal blanks 220 and 230.
HDCP is more particularly detailed in the HDCP Specification Rev. 1.2 and 1.3, made available by Digital Content Protection, LLC, the contents of which are hereby incorporated by reference.
Unfortunately, not all data streams include sufficient intervals (e.g. breaks) to accommodate HDCP re-keying. Such streams do not lend themselves to encryption using the traditional HDCP protocol. For example, HDCP does not lend itself to use in association with non-rasterized video, or other data streams.
The upcoming DisplayPort protocol, for example, defines a new video interconnect that does not include sufficient breaks to accommodate HDCP re-keying. More specifically, DisplayPort is intended initially for single-stream rasterized video, but may be extended to non-rasterized, multi-stream applications where there will be no predictable breaks in the datastreams. DisplayPort is more particularly described in The DisplayPort Standard, v. 1.0 and 1.1, as published by the Video Electronics Standards Association (VESA), the contents of which are hereby incorporated by reference.
New encryption protocols that do not require re-keying are options for such streams. However, HDCP has already been accepted by industry, and HDCP engines already form part of many receivers and transmitter.
Accordingly, there is a need for a new encryption technique that allows encryption of a wide variety of data streams using cipher engines, such as those used in HDCP systems that provide intermittent encryption streams.